Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / iesg / iesg.91-07-30 < prev next >

Wrap

Text File | 1993-02-04 | 16KB | 422 lines

IETF STEERING GROUP (IESG) MINUTES OF THE IESG MEETINGS DURING THE 21st IETF PLENARY JULY 30 AND AUGUST 2ND. Reported by: Greg Vaudreuil, IESG Secretary This report contains - Meeting Agenda - Meeting Attendees - Meeting Notes - Summary of Action Taken - Summary of Positons Taken Please contact IESG Secretary Greg Vaudreuil (iesg-secretary@nri.reston.va.us) for more details on any particular topic. LUNCH MEETING ------------- The IESG met for lunch Tuesday, July 30th to discharge action items, review the IETF meeting and plan for the upcoming open plenary. Attendees --------- Almquist, Philip / Consultant Borman, David / CRAY Callon, Ross / DEC Chiappa, Noel Crocker, Steve / TIS Coya, Steve / CNRI Davin, Chuck / MIT Estrada, Susan / CERFnet Gross, Philip / ANS Hobby, Russ / UC-DAVIS Reynolds, Joyce / ISI Stockman, Bernard / SUNET/NORDUnet Vaudreuil, Greg / CNRI Regrets Crocker, Dave / DEC Hinden, Robert / BBN Agenda ------ 1. Point to Point Protocol 2. SAAG report 3. Review of the OSI Area 4. Interaction between working groups and area directorates. Minutes ------- 1. Point to Point Protocol The Point to Point protocol working group met to discuss the future directions of the working group. Noel Chiappa was pleased to announce that Brian Lloyd will take a position as the new working group chairman. A revised charter is currently being written. 2. SAAG Report The Security Area Advisory Group met to discuss several outstanding issues. IP Security Option. The IPSO crowd agreed to agree to an arrangement by September 30th. The IESG was a bit confused by this, but recognized that this is at least a small step forward in resolving this thorny issue. Commercial IP Security Option. The SAAG was happy with this work in general. There is more work needed, both to give the existing work context, and to flesh out the protocol. 3. Review of the OSI Area Ross Callon opened a discussion on the relative positioning of working groups in the OSI area and in other IETF areas. Ross proposed that to increase the attention given to OSI issues, and enhance OSI's integration into the operational Internet by distributing some WG's to other appropriate areas. For example, groups like ODA and X.500 are clearly application level efforts designed to run as applications for the TCP-IP suite of Internet protocols, and it would be appropriate to move these group either to be in the Applications area, or to be joint between the OSI and Applications areas. I was pointed out that other efforts intended to foster the growth of OSI network layer and full stack efforts clearly need the special support of the OSI area. This special OSI support provides a focus for identifying OSI specific problems and insuring that they receive the management attention needed to resolve outstanding issues. It was also pointed out that some Area Directors are overloaded and some WG's are already not receiving the guidance and attention they need. Giving AD's further OSI WG's may in many cases reduce the attention these topics received, not enhance it. The IESG discussed this idea for a while and did not reach any firm conclusions but pledged to continue to investigate the integration of OSI protocols into the IESG. It was agreed that where appropriate it would make sense to move, or add joint responsibility, to some WG's, for example those bringing new OSI applications up in the TCP/IP stack. This discussion was given an element of immediacy by the recent departure of Rob Hagens from the IESG. The current stack of working groups and independent OSI engineering efforts is far to large for a single area director. 4. Working group, Area Directorate interactions. The Area Directorates of the IESG provide a level of essential guidance and service to working groups that is now indispensable. This system has been more or less formal across the full range of directorates. In particular, both the SAAG, and the Network Management Directorate provide direct expertise to working groups solving "real" problems, enabling them to make good progress while considering the full impact of their work on the security and network management infrastructure. The User Services area Council and the Operations area directorate are expected to provide a similar range of support in the near future. The IESG discussed this development, and attempted to formalize a mechanism for working groups to begin a liaison. Two primary mechanisms were identified. 1) All working group charters are reviewed by the full IESG prior to their formal formation. At this time an area director can assign resources or identify a need for future support. 2) Working groups engaged in writing a specific protocol may find a lack of expertise in one of the "overarching" areas, Security, Network Management, or Operations, and call in support. ACTION: Coya -- Write up the mechanisms for Directorate support of working groups in the IETF Handbook. IESG DINNER ----------- The IESG met for dinner Thursday, August 2nd to discharge action items, review the open plenary session, and craft recommendations on specific protocols. Attendees --------- Almquist, Philip / Consultant Chiappa, Noel / Consultant Crocker, Steve / TIS Coya, Steve / CNRI Davin, Chuck / MIT Estrada, Susan / CERFnet Gross, Philip / ANS Hobby, Russ / UC-DAVIS Hinden, Robert / BBN Reynolds, Joyce / ISI Stockman, Bernard / SUNET/NORDUnet Vaudreuil, Greg / CNRI Regrets Borman, David / CRAY Callon, Ross / DEC Crocker, Dave / DEC Guests Steve Kent/ BBN Agenda ------ 1. Review of Protocol Actions - MIB II - Concise MIB - IP over Frame Relay - Router Discovery - Bridge MIB - Remote Monitoring MIB - FDDI MIB - Decnet Phase IV MIB 2. Distinguished Names 3. RFC Editor Actions - Finger revisions 4. IPLPDN and the IP routing model 5. Review results of the IP Addressing BOF 6. Next Meeting Minutes ------- 1. Protocol Actions 1.1 MIB II To Full Standard The IESG agreed to recommend the elevation of MIB II to Full Standard. This will be the first Full Standard progressed entirely under the modern standards system. 1.2 Concise MIB to Draft Standard The IESG agreed to recommend this new format for MIB definitions as a Draft Standards. 1.3 Network Time Protocol Version 3. This IESG agreed to recommend the publication of this protocol as a Proposed Standard. It was developed by David Mills and reviewed by a technical review committee appointed by Craig Partridge. Steve Kent pointed out that version 2 of this protocol is clearly spoofable. The PSRG reviewed this protocol and concluded that any known security mechanism would excessively burden the protocol. The analogy used was that of delivering a letter by registered mail telling you that it was six o'clock. It is not clear whether version 3, the current version addresses the security weakness, but it was suggested that this security weakness should at least be noted in the document. The IESG concluded that this protocol has been delayed excessively and was unwilling to hold it up further. If security is not adequately addressed in this document, it may be added in the Draft Standard. 1.4 IP over Frame Relay The IESG agreed to recommend the publication of this protocol as a proposed standard. The IESG discussed the implications of using both the NLPID and the SNAP header for identification of the protocol being carried, and agreed that it seemed a tad awkward, but agreed that it would work and that the working group had good reason to specify the protocol in this manner. 1.5 Router Discovery Protocol The IESG agreed to recommend the publication of this protocol as a proposed standard pending the clarification of one technical point. The security issues raised previously have been addressed by adding text to the document explaining the security limitations of this protocol as well as a configuration flag to disable both use of this protocol and processing of unsolicited packets. A concern was raised by Steve Kent about the accepting of default router announcements if the host has been configured. ACTION: Chiappa -- Investigate the router discover protocol and confirm that a configuration mechanism exists to turn off the acceptance of default router announcements if the host is properly configured. 1.6 IEEE 802 Bridge MIB, FDDI MIB, Remote Monitoring MIN, Decnet Phase IV MIB These MIB's were reviewed by the Network Management directorate, and all were found to be acceptable with a few editorial and syntactic changes. Final versions will be posted to the Internet Drafts directory and the IESG will consider them for proposed standard at that time. The letter to the IEEE explaining the IAB policy on external MIB's needs to be sent when the protocol is approved for Proposed Standard. 2. Distinguished names. The need for a distinguished name registry is becoming increasingly important as PEM and the CAT groups near completion. The registry is a necessary component of the deployment on many security services on the Internet. The IESG did not have time to discuss this in detail, but took an action to discuss it in the future. ACTION: Greg Vaudreuil -- Schedule a discussion on distinguished names at an upcoming IESG Teleconference. 3. RFC Editor Actions 3.1 Finger User Information Protocol The RFC Editor has received a new version of the Finger document. This new document makes several changes to the protocol to bring the specification more closely into line with existing implementations of this protocol. The RFC Editor requested the IESG investigate this protocol to determine the correct course of action. POSITION: If the revision to the Finger protocol amounts to a technical bug fix, or clarifies the specification of the operation of the protoco , the protocol may remain at Draft Standard, but if the change introduces new functionality, or changes the behavior of the protocol, it will need to be reissued as a proposed standard. ACTION: Vaudreuil -- Send a note to the RFC Editor requesting that he send the document to the IESG for review. 4. IPLPDN Working Group and the IP Model The IP over Large Public Data Networks working group has begun exploring novel ways to connect together different IP networks which reside on a common SMDS network without using IP routers. The triggered the IESG to review the IP routing model, to determine if such a change to the architecture is reasonable. The standard IP model holds among other points: - IP networks (or IP subnets) are connected by an IP router - a redirect is sent to the originating host by the first hop (i.e. directly connected) router when the current first hop router is not the best first hop router for that destination. - hosts on one IP network (or IP subnet) can only communicate with hosts on another IP network (" " ") by going through an IP router - the process of turning an IP address into a local network address is a completely separate step from picking the IP address of the next hop; this former step is insulated entirely in the code which interfaces IP to a given local network The IPLDPN is considering several schemes to allow hosts (and routers) on distinct "logical" IP networks which share a common SMDS physical network to communicate directly without the necessaity of taking a useless "extra hop" through an IP router. The details vary, but in general they involve tighter integration of the local address resolution process with IP level routing. After reviewing these to points, the IESG agreed that the approach currently being considered by the IPLPDN Working Group is not in conformance with the current model, and without a compelling reason, the IESG will not change the IP routing architecture. These systems all require knowledge of the local address resolution scheme to be propogated into the IP layer of hosts. In addition, the IP routing architecture is about to go through a period of substantial stresss and modification, and it is felt that this process will be easier if the existing model is adhered to. It was also pointed out that what these proposals effectively were was an attempt at a "quick-and-dirty" SMDS (and IP) specific solution to the problems of address resolution in a large WAN. It was the opinion of some that this was not their understanding of what the WG's goal was when it was set up; rather, it was thought that the group was to consider the issues of address resolution and routing in large WAN's, and attempt to design or adapt common mechanisms to handle these issues, much as ARP was a general attack on the problem of address resolution in small broadcast LAN's. ACTION: Chiappa and Hinden -- Investigate the specifics of the IPLPDN working group's efforts both in address resolution and routing to determine what direction the working group may need. 5. Results of the Address Hacks BOF The IP address space BOF met as a 20 minute working group to discuss the various proposals for increasing the number of IP network numbers in a manner which will optimize the use of the remaining address space without adversely affecting routing. The proposal from the group involves the definition of a new class E address with a 16 bit network number and a 12 bit rest. These addresses will use all the currently unallocated portion of the address space; i.e. that part with a '1111' prefix'. (The entire space was allocated since the custom of making the prefix longer and longer at each class is resulting in less useful spaces. A new reserved space will be created from an unallocated portion of the class A space.) An argument was made in the BOF session for using the back half of the class C addresses. This latter approach would be nominally interoperable with current routing software, but it causes 16 (2^4, since there are 4 more bits in the 'rest' field of this class) routing table entries for each new network installed. Given a problem with scaling already present, this was after some consideration deprecated as an impracticable idea. Complete minutes of the meeting will be prepared and be included in the proceeding for this IETF Meeting. ACTION: Chiappa -- Write up the thoughts of the 20 minutes working group as a proposal for a new class of IP addresses 6. Next Meeting The Next IESG Teleconference was scheduled for August 8th, 12:00 PM to 2 PM EST. Summary of Actions ------------------- ACTION: Coya -- Write up the mechanisms for Directorate support of working groups in the IETF Handbook. ACTION: Chiappa -- Investigate the router discover protocol as confirm that a configuration mechanism exists to turn off the acceptance of default router announcements after the host is properly configured. ACTION: Greg Vaudreuil -- Schedule a discussion on distinguished names at an upcoming IESG Teleconference. ACTION: Vaudreuil -- Send a note to the RFC Editor requesting that he send the document to the IESG for review. ACTION: Chiappa and Hinden -- Investigate the specifics of the IPLPDN working group's efforts both in address resolution and routing to determine the what direction the working group may need. ACTION: Chiappa -- Write up the thoughts of the 20 minutes working group as a proposal for a new class of IP addresses Summary of Positions -------------------- POSITION: If the revision to the Finger protocol amounts to a technical bug fix, the protocol may remain at Draft Standard, but if the change introduces new functionality, or changes the behavior of the protocol, it will need to be reissues as a proposed standard.